The telecommunications industry has become more concerned with service delivery to end users and service consumers. The most accurate measurements for assessing the quality of the service delivery are those reported by the end user device. Therefore the information provided by terminal reporting about the quality of the service delivery has become more critical to the operator's business because the operator can measure fluctuations in the quality of delivered services and therefore understand the end-user perception of the quality of services most accurately by measuring quality of services delivered at the terminal.
The challenge for a communication network operator is to balance the impact on the network resources of the additional network load caused by the terminal reporting against the benefits of terminal reporting on the ability of the communication network operator to manage the quality delivered by the communication network for different services.
In the present description, a terminal is defined as an entity that runs a service session. For example, in the case of an Internet Protocol Television (IPTV) service, the terminal might be a TV set, a set top box, or a software program running on a computer.
A number of solutions have been proposed to measure so-called quality of service (QoS) or quality of experience (QoE) metrics and report end user device service quality measurements as set out in the following description. Each individual solution includes mechanisms that allow the network operator to control the load on the communication network caused by measurement reporting load.
The following paragraphs present a brief summary of existing solutions for resource constrained terminal reporting.
The quality of experience (QoE) reporting mechanisms of the 3rd Generation Partnership Project technical specification 3GPP TS 26.234 (Packet-switched Streaming Service (PSS)) and the 3rd Generation Partnership Project technical specification 3GPP TS 26.346 (Multimedia Broadcast/Multicast Service (MBMS)) specify that the quality of experience (QoE) metrics for a service session are reported after the service session via the reception reporting procedure using hypertext transport protocol (HTTP), session description protocol (SDP) or real time streaming protocol (RTSP) in a single transmission control protocol (TCP) session.
For example, the session and media-level attribute “a=3GPP-QoE-Metrics” is used to negotiate the usage of the quality of experience (QoE) metrics. The included parameters indicate which metrics, and the duration over which the metrics should be measured, and how often reports should be sent.
In particular, “Sending-Rate” defines the maximum time period in seconds between two successive quality of experience QoE reports. The shortest interval is one second. The reporting interval can be different for different media. The value “End” indicates that only one report is sent at the end of the session.
The optional “Measure-Resolution” field defines a time over which each metrics value is calculated. The “Measure-Resolution” field splits the session duration into a number of equally sized periods where each period is of the length specified by the “Measure-Resolution” field. The “Measure-Resolution” field is thus defining the time before the calculation of a quality of experience QoE parameter re-starts. If the “Measure-Resolution” field is not present the metrics resolution shall cover the period specified by the “Measure-Range” field. If the “Measure-Range” field is not present the metrics resolution shall be the whole session duration.
The quality of experience QoE metrics are calculated for each period specified by the “Measure-Resolution” field and stored in the terminal, and all the stored metrics are then sent together according to the “Sending-Rate” field. This allows long reporting intervals thus saving bandwidth without losing good metric measurement resolution. It is recommended that the Sending-Rate is set to an integer multiple of the Measure-Resolution, or to “End”.
A mechanism to randomize terminal reporting of a population of terminals is described in the 3rd Generation Partnership Project technical specification for Multimedia Telephony Service for IMS 3GPP TS 26.114(MTSI), paragraph 16.3.3.
The SamplePercentage rule is used to set a percentage sample of calls that should report reception. This can be useful for statistical data analysis of large populations while increasing scalability due to reduced total uplink signalling. The sample_percentage parameter takes on a value between 0 and 100, including the use of decimals. It is recommended that no more than 3 digits follow a decimal point (e.g. 67.323 is sufficient precision).
When the SamplePercentage rule is not present or its sample_percentage parameter value is 100 each MTSI client terminal shall send metric report(s). If the sample_percentage value is less than 100, the MTSI client terminal generates a random number that is uniformly distributed in the range of 0 to 100. The MTSI client terminal sends the reception report when the generated random number is of a lower value than the sample_percentage value.
The LimitSessionInterval rule is used to limit the time interval between consecutive calls that report metrics. The min_interval parameter for this rule indicates the minimum time distance between the start of two calls that are allowed to report metrics. When this rule is absent there is no limitation on the minimum time interval.
When multiple rules are defined in the Management Object, the MTSI client should only report metrics when all individual rules evaluate to true (i.e. the rules are logically ANDed). When no rules are present the MTSI client should always report metrics.
An example for a QoE metric reporting rule is shown below:
3GPP-QoE-Rule: OnlyCallerReports, SamplePercentage; sample_percentage=10.0, LimitSessionInterval; min_interval=300,
This example rule defines that only a caller terminal shall report, and only for 10% of the sessions, with the minimum time interval between the start times of two consecutive calls that report metrics to be 5 minutes.
RTCP (Real-time Transport Control Protocol) periodically transmits control packets to participants (including multiple content senders and multiple content receivers) in a real-time transport protocol (RTP) based streaming multimedia session, enabling group size estimation and the distribution and calculation of session-specific information such as packet loss and round trip time to other hosts.
As defined in RFC 3550, the Real-time Transport Control Protocol (RTCP) traffic is limited to a small and known fraction of the Real-time Transport Control Protocol RTCP session bandwidth. This determination is based on some cost or a priori knowledge of the available network bandwidth for the session and the sum of the nominal bandwidths of the senders expected to be concurrently active. The fraction of the bandwidth available for the Real-time Transport Control Protocol (RTCP) traffic is small so that the primary function of the transport protocol to carry data is not impaired and is known so that the control traffic can be included in the bandwidth specification given to a resource reservation protocol, and so that each participant can independently calculate its share. It is recommended that the fraction of the session bandwidth added for Real-time Transport Control Protocol (RTCP) traffic be fixed at 5%.
The calculation of Real-time Transport Control Protocol (RTCP) receiver reporting (RR) interval is as follows (assuming receiver reports takes ¾ of the overall Real-time Transport Control Protocol (RTCP) bandwidth):
  number  ⁢          ⁢  of  ⁢          ⁢  receivers  ×            average      ⁢                          ⁢      RTCP      ⁢                          ⁢      packet      ⁢                          ⁢      size              0.75      ×      RTCP      ⁢                          ⁢      bandwidth      
The Broadband Forum (formerly DSL Forum) technical report TR-069 specifies a protocol for communication between an Auto-Configuration Server (ACS) and Customer Premise Equipment (CPE). The Auto-Configuration Server (ACS) is a server within the service provider's network that has the ability to control and monitor a Customer Premise Equipment (CPE) with the TR-069 protocol.
The Customer Premise Equipment (CPE) wide area network (WAN) Management Protocol is intended to support a variety of functions to manage a collection of Customer Premise Equipment (CPE), including: auto-configuration and dynamic service provisioning; software/firmware image management; status and performance monitoring; and diagnostics. The data model is defined by the Broadband Forum in technical report TR-106.
The Broadband Forum (formerly DSL Forum) technical report TR-069 framework does not specify any mechanism for specifying, controlling or throttling terminal measurements. Such functions may be implemented as vendor specific extensions.
The internet Engineering taskforce IETF request for comment document RFC 3550 describes a generic design of dynamic quality of service (QoS) reporting rate, for the purpose of reporting overhead reduction, In order to prevent control traffic from overwhelming network resources and to allow Real-time Transport Protocol RTP to scale up to a large number of session participants, Real-time Transport Control Protocol RTCP control traffic is limited to at most 5% of the overall session traffic. This limit is enforced by adjusting the rate at which Real-time Transport Control Protocol RTCP packets are periodically transmitted as a function of the number of participants.
Internet Engineering Task Force IETF RFC 5760 “RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback” proposes a hierarchical terminal report aggregation model, aiming at increasing the maximum number of users limit and enabling Quality of Service (QoS) measurement for those users.
The proposed hierarchical Real-time Transport Control Protocol RTCP feedback aggregation solution is used with Source-Specific Multicast where only a single source is permitted and allows intermediate nodes (“feedback targets”) or the distribution source to summarize quality of service (QoS) information received from all the receiver reports generated by terminals and place the summarised quality of service (QoS) information into summary reports. The transmission of summary quality of service reports instead of original quality of service reports results in a saving in required bandwidth.
The invention seeks to at least ameliorate the disadvantages of the prior art and to provide a method and apparatus for quality of service monitoring of multiple services in a communication network.